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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
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Abstract 


This document defines a number of terms useful for the discussion of 
Internet Fax. In addition, it describes the goals of the Internet Fax 
working group and establishes a baseline of desired functionality 
against which protocols for Internet Fax can be judged. It 
encompasses the goals for all modes of facsimile delivery, including 
‘real-time’, ’session’, and ’store and forward’. Different levels of 
desirability are indicated throughout the document. 
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1. Introduction 


Facsimile (Fax) has a long tradition as a telephony application for 
sending a document from one terminal device to another. 


Many mechanisms for sending fax documents over the Internet have been 
demonstrated and deployed and are currently in use. The general 
application of using the Internet for facsimile is called "Internet 
Fax". 


This document defines a number of terms useful for the discussion of 
Internet Fax. In addition, it describes the goals for Internet Fax and 
establishes a baseline of desired functionality against which 
protocols for Internet Fax can be judged. It encompasses the goals for 
all modes of facsimile delivery, including "real-time", "session", and 
"store and forward" (terms defined in Section 2 of this document). 


1.1 Terminology used within this document 


Within this document, different levels of desirability for a protocol 
for Internet Fax are indicated by different priorities, indicated in 
{braces}: 


{1} there is general agreement that this is a critical 
characteristic of any definition of Internet Fax. 

{2} most believe that this is an important characteristic 
of Internet Fax. 

{3} there is general belief that this is a useful feature 
of Internet Fax, but that other factors might override; 
a definition that does not provide this element is 
acceptable. 
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In addition, the following terms are used: 


"service" An operational service offered by a service provider. 
"application" A use of systems to perform a particular function. 
"terminal" The endpoint of a communication application. 

"goal" An objective of the standarization process. 


2. Definitions and Operation Modes 
This section defines some of the basic terms for Internet Fax. 
2.1 User model of fax and basic operations 


The phrase "traditional facsimile" or "G3Fax" is used to denote 
implementations of [T.30]. Facsimile (fax) is a telephony application 
for sending a document from one terminal device to another. 


The telephone network is often referred to as the Public Switched 
Telephone Network (PSTN) or Global Switched Telephone Network (GSTN). 


Communication over the telephone network is accomplished using 
modems. The transmission of data end-to-end is accompanied by 
negotiation (to ensure that the scanned data can be rendered at the 
recipient) and confirmation of delivery (to give the sender assurance 
that the final data has been received and processed.) Over time, 
facsimile has been extended to allow for PCs using fax modems to send 
and receive fax, to send data other than scanned facsimile images. In 
addition, there have been many extensions to the basic image model, 
to allow for additional compression methods and for representation of 
images with grey-scale and color. Other delivery extensions have 
included sub-addressing (additional signals after the call is 
established to facilitate automated routing of faxes to desktops or 
mailboxes), and enhanced features such as fax-back and polling. 


Typically, the terminal device consists of a paper input device 
(scanner), a paper output device (printer), with (a limited amount 
of) processing power. Traditional facsimile has a simple user 
operational model; the user 


inserts paper into a device 

dials a number corresponding to the destination 

presses the ’start’ button on the device 

the sending device connects to the receiving device using the 

telephone network 

5) the sending device scans the paper and transmits the image of 
the paper 

6) simultaneously, the remote device receives the transmission and 

prints the image on paper 
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7) upon completion of transmission and successful processing by 
the recipient, the sending user is notified of success 


Although not usually visible to the user, the operation (5) of 
transmission consists of 


5a) negotiation: the capabilities of the recipient are obtained, 
and suitable mutually available parameters for the 
communication are selected 

5b) scanning: creating digitized images of pages of a document 

5c) compression: the image data is encoded using a data 
compression method 

5d) transmission: the data is sent from one terminal to the other 


In addition, the terminiation of operations (5d) and (6) may be 
characterized as consisting of: 


6a) completed delivery: the message has completed transmission 

6b) completed receipt: the message has been accepted by the 
recipient 

6c) processing and disposition: the message has been processed 


From a protocol perspective, the information conveyed in the 
transmission consists of both "protocol" (control information, 
capabilities, identification) and also "document content". 


The document content consists primarily of the "document image" plus 
additional metadata accompanying the image. The means by which an 
image of a document is encoded within the fax content is the "image 
data representation". 


When the fax has been successfully transmitted, the sender receives a 
"confirmation": an indication that the fax content was delivered. 
This "confirmation" is an internal signal and is not normally visible 
to the sending user, although some error messages are visible, to 
allow a page to be retransmitted. 


2.2 Definition of Internet Fax 


The phrase "Internet Fax" is used to denote an application which 
supports an approximation to the user model of fax (Section 2.1), but 
where Internet protocols are used instead of the telephone network 
for (some portion of) the transmission. The exact modes and 
operations of traditional facsimile need not be duplicated exactly. 
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2.3 Internet Fax Roles 


Internet Fax is a document transmission mechanism between various 
different devices and roles. Those devices and roles might come ina 
wide variety of configurations. To allow for a wide variety of 
configurations, it is useful to separate out the roles, as they may 
be made available separately or in combination. These roles are: 


* Network scanner 
A device that can scan a paper document and transmit the scanned 
image via the Internet 


* Network printer 
A device that can accept an image transmission via the Internet 
and print the received document automatically 


* Fax onramp gateway 
A device that can accept a facsimile telephone call and 
automatically forward it via the Internet 


* Fax offramp gateway 
A device that can accept a transmission from the Internet and 
forward it to a traditional fax terminal 


In addition, other traditional Internet applications might also 
participate in Internet Fax, including Internet mail users, Web 
browsers, Internet printing hosts. 


2.4 Internet Fax Devices 


The Internet Fax roles may be embedded in a variety of combinations 
and configurations within devices and larger applications. They may 
be combined with other elements, e.g., a traditional T.30 fax device. 
Many different configurations of applications and systems should {2} 
be able to participate in Internet Fax; the specification should not 
unnecessarily restrict the range of devices, applications and 
services that can participate. 


A device that supports Internet Fax might support any combination of 
the roles defined in 2.3. 


2.4.1 Gateway devices 


A traditional fax terminal has a telephone line connection (GSTN) 
with a fax modem used to connect over the telephone network. To 
connect a fax terminal to the Internet requires a service which 
offers connections on one side to the GSTN using standard fax 
signals, and on the other side to the Internet. This role might be 
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performed by a "relay" (e.g., transmitting T.30 signals over real- 
time controlled TCP connections) or a "gateway" (e.g., translating 
T.30 to TIFF/email). 


With these applications, the role of Internet Fax is to transport the 
fax content across the Internet, e.g., with 


[fax-term] -GSTNfax-—>[onramp]-Internet Fax->[recipient] 
[sender]-Internet Fax->[offramp] -GSTNFax->[fax-term] 


A onramp and/or offramp application may be local to a single fax 
terminal. For example, the gateway application might exist within a 
small device which has a telephone interface on one side anda 
network connection on the other. To the fax machine, it looks like a 
telephone connection, although it might shunt some or all connections 
to Internet Fax instead (Such devices are called "Bump-in-cord.") 


An onramp or offramp application may be a local facility serving many 
fax terminals. For example, outgoing telephone fax calls through a 
company telephone PBX could be rerouted through a local onramp. An 
internet to telephone outbound connection could be part of a "LAN 
Fax" package. 


Onramps and offramps may serve a wider area or broader collection of 
users, e.g., services run by service bureaus, offering subscription 
services; the telephone sender or the recipient might subscribe to 
the service. 


The target of an offramp may be a "hunt group": a set of telephone 
numbers, each of which have a possibly different fax terminal 
attached. 


2.4.2 New "Internet Fax" devices 


Manufacturers may offer new devices which support any combination of 
the roles defined in setion 2.3. In particular, a device resembling a 
traditional fax terminal, built out of similar components (scanner, 
processor, and printer), could offer a similar functionality to a 
traditional facsimile terminal, but be designed to connect to the 
Internet rather than, or in addition to, a telephone line connection. 


Such devices might have a permanent Internet connection (through a 


LAN connection) or might have occasional connectivity through a 
(data) modem to an Internet Service Provider. 
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2.4.3 Internet hosts 


Internet users using Internet hosts with standard application suites 
must {1} be able to exchange faxes with other participants in 
Internet Fax, with minimum required enhancements to their operating 
environment. 


Interoperability with Internet mail users, either as Internet Fax 
senders or recipients, is highly desirable {2}. 


Internet users might receive faxes over the Internet and display them 
on their screens, or have them automatically printed when received. 
Similarly, the Internet Fax messages originating from the user might 
be the output of a software application which would normally print, 
or specially constructed fax-sending software, or may be input 
directly from a scanner attached to the user’s terminal. 


The Internet Fax capability might be integrated into existing 
fax/network fax software or email software, e.g., by the addition of 
printer drivers that would render the document to the appropriate 
content-type and cause it to be delivered using an Internet Fax 
protocol. 


In some cases, the user might have a multi-function peripheral which 
integrated a scanner and printer and which gave operability similar 
to that of the stand-alone fax terminal. 


2.4.4 Internet messaging 


In Internet mail, there are a number of components that operate in 
the infrastructure to perform additional functions beyond mail 
store-and-forward. Interoperability with these components is a 
consideration for the store and forward profile of Internet Fax. For 
example, mailing list software accepts mail to a single address and 
forwards it to a distribution list of many users. Mail archive 
software creates repositories of searchable messages. Mail firewalls 
operate at organizational boundaries and scan incoming messages for 
malicious or harmful mail attachments. Vacation programs send return 
messages to the senders of messages when the recipient is on vacation 
and not available to respond. 


2.4.5 Universal messaging 
Many software vendors are now promoting software packages that 


support "universal messaging": a combined communication package that 
combines electronic mail, voice mail, and fax. 


Masinter Informational [Page 7] 


RFC 2542 Terminology and Goals for Internet Fax March 1999 


2.5 Operational Modes for Internet Fax 


Facsimile over the Internet can occur in several modes. 


"Store and forward" Internet Fax entails a process of storing the 
entire document at a staging point, prior to transmitting it to the 
next staging point. Store and forward can be directly between sender 
and recipient or can have a series of intermediary staging points. 
The intermediate storage may involve an intermediate agent or 
sequence of agents in the communication. 


"Session" Internet Fax is defined such that delivery notification is 
provided to the transmitting terminal prior to disconnection. Unlike 
"store and forward", there is an expection that direct communication, 
negotiation, and retransmission can take place between the two 
endpoints. 


"Real-time" Internet Fax allows for two [T.30] standard facsimile 
terminals to engage in a document transmission in a way that all of 
the essential elements of the [T.30] communication protocol are 
preserved and there is minimal elongation of the session as compared 
to Group 3 fax over the GSTN. 


These modes are different in the end-user expectation of immediacy, 
reliability, and in the ease of total compatibility with legacy or 
traditional facsimile terminals; the modes may have different 
requirements on operational infrastructure connecting sender and 
recipient. 


3. Goals for Internet Fax 


Facsimile over the Internet must define the mechanisms by which a 
document is transmitted from a sender to a recipient, and must {1} 
specify the following elements: 


- Transmission protocol: what Internet protocol(s) and extensions 
are used? What options are available in that transmission? 


- Data formats: what image data representation(s) are used, 
appropriate, required, within the transmission protocol? What 
other data representations are supported? 


- Addressing: How are Internet Fax recipients identified? How may 


recipient identification be represented in user directories? How 
are traditional fax terminals addressed? 
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- Capabilities: The capabilities of the sender to generate 
different kinds of image data representations may be known to 
the recipient, and the capabilities, preferences, and 
characteristics of the recipient may be known to the sender. How 
are the capabilities, preferences, and characteristics of 
senders and recipients expressed, and communicated to each 
other? 


- Security: Faxes may be authenticated as to their origin, or 
secured to protect the privacy of the message. How may the 
authenticity of a fax be determined by the recipient? How may 
the privacy of a message be guaranteed? 


Specific goals for these elements are described in section 5. 
4. Operational Goals for Internet Fax 


This section lists the necessary and desirable traits of an Internet 
Fax protocol. 


4.1 Functionality 


Traditionally, images sent between fax machines are transmitted over 
the global switched telephone network. An Internet Fax protocol must 
{1} provide for a method to accomplish the most commonly used 
features of traditional fax using only Internet protocols. It is 
desirable {3} for Internet Fax to support all standard features and 
modes of standard facsimile. 


4.2 Interoperability 


It is essential {1} that Internet Fax support interoperability 
between most of the devices and applications listed in section 2, and 
desirable {3} to support all of them. To "Support interoperability" 
means that a compliant sender attempting to send to a compliant 
recipient will not fail because of incompatibility. 


Overall interoperability requires {1} interoperability for all of the 
protocol elements: the image data representations must be understood, 
the transport protocol must function, it must be possible to address 
all manner of terminals, the security mechanism must not require 
manual operations in devices that are intended for unattended 
operation, and so forth. 


Interoperability with Internet mail user agents is a requirement {1} 
only for the "store-and-forward" facsimile, although it would be 
useful {3} for "session" and "real-time" modes of delivery of 
Internet Fax. 
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The requirement for interoperability has strong implications for the 
protocol design. Interoperability must not {1} depend on having the 
same kind of networking equipment at each end. 


As with most Internet application protocols, interoperability must 
{1} be independent of the nature of the networking link, whether a 
simple IP-based LAN, an internal private IP networks, or the public 
Internet. The standard for Internet Fax must {1} be "global": that 
is, a single specification which does not have or require special 
features of the transport mechanism for local operations. 


If Internet Fax is to use the Internet mail transport mechanisms, it 
must {1} interoperate consistently with the current Internet mail 
environment, and, in particular, with the non-terminal devices listed 
in section 2.4.4. If Internet Fax messages might arrive in user’s 
mailboxes, it is required {1} that the protocol interoperate 
successfully with common user practices for mail messages: storing 
them in databases, retransmission, forwarding, creation of mail 
digests, replay of old messages at times long after the original 
receipt, and replying to messages using non-fax equipment. 


It is desirable {3} that the Internet Fax standard support and 
facilitate universal messaging systems described in section 2.4.5. 


If Internet Fax requires additions to the operational environment 
(services, firewall support, gateways, quality of service, protocol 
extensions), then it is preferable {3} if those additions are useful 
for other applications than Fax. Features shared with other messaging 
applications (voice mail, short message service, paging, etc.) are 
desirable {3}, so as not to require different operational changes for 
other applications. 


4.3 Confirmation 


In almost all applications of traditional fax, it is considered very 
important that the user can get an assurance that the transmitted 
data was received by a terminal at the address dialed by the user. 


This goal translates to the Internet environment. The ’Internet Fax’ 
application must {1} define the mechanisms by which a sender may 
request notification of the completion of transmission of the 
message, and receive a determinate response as to whether the message 
was delivered, not delivered, or that no confirmation of delivery is 
possible. 


Originally, fax "confirmation" implied that the message was received 


and processed, e.g., delivered to the output paper tray of the 
recipient fax device. In reality, this implication was relying upon 
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a signal produced by the receiving terminal that the incoming page 
had been inspected and was determined to be of reasonable (or 
unacceptable) quality, via an unspecified algorithm. 


In later devices which support error correction mode, the ECM method 
(per [T.30]) enabled error checking via a specific algorithm, 
providing a more exact indication that the bits within the compressed 
image were not corrupted during transmission. With the addition of 
memory buffering, PC-based fax modems and the more common use of 
error correction mode, traditional fax confirmation still implies 
some assurance of processability; (e.g., a fax modem would not be 
able to receive an incoming fax if it required compression mechanisms 
that were not supported) without reporting on whether the image has 
been printed or viewed. 


Consequently, the fax confirmation is not the same as a confirmation 
that the message was "read": that a human had confirmed that the 
message was received. It is desirable {3}, but not required, that 
Internet Fax support confirmation that a message has been read (above 
and beyond the confirmation that the message has been delivered). 


4.4 Quick Delivery 


In many cases, fax transmission is used for delivery of documents 
where there is a strong user requirement for timeliness, with some 
guarantees that if transmission begins at all, it will complete 
quickly. For example, it is a common practice to fax documents for 
discussion to other participants in a telephone conference call prior 
to the call. 


Internet Fax should {2} allow the sender of a document to request 
immediate delivery, if such delivery is possible. In such cases, it 
should {2} be possible for the sender of a message to avoid sending 
the message at all, if quick delivery is not available for a 
particular recipient. 


It is desirable {3} to have the protocol for requesting quick 
delivery be the same as, or similar to, the protocol for delayed 
delivery, so that two separate mechanisms are not required. 


For real-time fax delivery, immediate delivery is the norm, since the 
protocol must guarantee that when the session connecting sender to 
recipient has terminated, the message has been delivered to the 
ultimate recipient. 
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4.5 Capabilities: reliable, upgrade possible 


Traditionally, facsimile has guaranteed interworking between senders 
and recipients by having a strict method of negotiation of the 
capabilities between the two devices. The image representation of 
facsimile originally was a relatively low resolution, but has 
increasingly offered additional capabilities (higher resolution, 
color) as options. 


The use of fax has grown in an evolving world (from ’Group 1’ and 
"Group 2’, to '’Group 3’ facsimile) because of two elements: (a) a 
useful baseline of capabilities that all terminals implemented, and 
(b) the use of capabilities exchange to go beyond that. 


To accommodate current use as well as future growth, Internet Fax 
should {2} have a simple minimum set of required features that will 
guarantee interoperability, as well as a mechanism by which higher 
capability devices can be deployed into a network of lower capability 
devices while ensuring interoperability. If recipients with minimum 
capabilities were, for example, to merely drop non-minimum messages 
without warning, the result would be that no non-minimum message 
could be sent reliably. This situation can be avoided in a variety of 
ways, e.g., through communication of recipient capabilities or by 
sending multiple renditions. 


The exchange of capabilities in Internet Fax should {2} be robust. To 
accomplish this, recipients should {2} be encouraged to provide 
capabilities, even while senders must {1} have a way to send messages 
to recipients whose capabilities are unknown. 


Even minimum-capability recipients of messages should {2} be required 
to provide a capability indication in some reliable way. This might 
be accomplished by providing an entry in a directory service, by 
offering automatic or semi-automatic replies, or by sending some 
indication of in a reply to a message with multiple renditions, or as 
an addition to a negative acknowledgement requiring retransmission. 


On the other hand, for reliability, senders cannot rely on capability 
information of recipients before transmission. That is, for 
reliability, senders should {2} have an operational mode which can 
function when capabilities are not present, even when recipients must 
always provide capabilities. 


4.6 Simplicity 
Internet Fax should not {2} require terminals to possess a large 


amount of processing power, and a base level implementation must {1} 
interoperate, even if it does not offer complex processing. 
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Internet Fax should {2} allow interoperability with recipient devices 
which have limited buffering capabilities and cannot buffer an entire 
fax message prior to printing, or cannot buffer an entire set of fax 
pages before beginning transmission of scanned pages. 


Different operational modes (real-time, session, store and forward) 
might use different protocols, in order to preserve the simplicity of 
each. 


It is preferable {3} to make as few restrictions and additions to 
existing protocols as possible while satisfying the other 
requirements. It is important {2} that it be possible to use 
Internet Fax end-to-end in the current Internet environment without 
any changes to the existing infrastucture, although some features may 
require adoption of existing standards. 


4.7 Security: Cause No Harm, Allow for privacy 


The widespread introduction of Internet Fax must {1} not cause harm, 
either to its users or to others. For example, an automatic mechanism 
for returning notification of delivery or capabilities of fax 
recipients by email must {1} not expose the users or others to mail 
loops, bombs, or replicated delivery. Automatic capability exchange 
based on email might not be sufficiently robust and, without 
sufficient precautions, might expose users to denial of service 
attacks, or merely the bad effects of errors on the part of system 
administrators. Similar considerations apply in these areas to those 
that have been addressed by work on electronic mail receipt 
acknowledgements [RFC 2298]. 


Internet Fax should {2} not, by default, release information that the 
users consider private, e.g., as might be forthcoming in response to 
a broadcast requests for capabilities to a company’s Internet fax 
devices. Public recipients of Internet Fax (e.g., public agencies 
which accept facsimile messages) should {2} not be required to 
broadcast messages with capability statements to all potential 
senders in order to receive facsimile messages appropriate for the 
capabilities of their device. 


The possibility for "causing harm" might be created by a combination 
of facilities and other features which individually may be viewed as 
harmless. Thus, the overall operation of a network full of Internet 
Fax devices must {1} be considered. 


Interoperation with ITU defined T.30 fax security methods, as well as 
standard Internet e-mail security methods is desirable {3}. 
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4.8 Reliability 


The Internet Fax protocol should {2} operate reliably over a variety 
of configurations and situations. 


In particular, operations which rely on time-delayed information 
might result in inconsistent information, and the protocol should be 
robust even in such situations. 


For example, in a store-and-forward message environment, the 
capabilities and preferences of a fax recipient might be used by the 
sender to construct an appropriate message, e.g., sending a color fax 
to a color device but a black and white fax to a device that does not 
have color capability. However, the information about recipient 
capabilities must be accessible to the sender even when the recipient 
cannot be contacted directly. Thus, the sender must access recipient 
capabilities in some kind of storage mechanism, e.g., a directory. A 
directory of recipient capabilities is a kind of distributed 
database, and would be subject to all of the well-known failure modes 
of distributed databases. For example, update messages with 
capability descriptions might be delivered out of order, from old 
archives, might be lost, non-authenticated capability statements 
might be spoofed or widely distributed by malicious senders. The 
Internet Fax protocol should {2} be robust in these situations; 
messages should {2} not be lost or misprocessed even when the 
sender’s knowledge of recipient capabilities are wrong, and robust 
mechanisms for delivery of recipient capabilities should {2} be used. 


4.9 User Experience 
The primary user experience with fax is: 
immediate delivery 


delivery confirmation 
ease of use 


The primary user experience with email is: 


delayed delivery 

no delivery confirmation 

ability to reply to sender 

easy to send to multiple recipients 


An Internet Fax standard should {2} attempt to reconcile the 
differences between the two environments. 
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4.10 Legal 


An Internet Fax standard should {2} accomodate the legal requirements 
for facsimile, and attempt to support functionality similar to that 
legally required even for devices that do not operate over the public 
switched telephone network. 


The United States Federal Communication Commission regulations 
(applicable only within the USA) state: 


Identification Required on Fax Messages 


The FCC’s rules require that any message sent to a fax machine 
must clearly mark on the first page or on each page of the 
message: 


the date and time the transmission is sent; 

the identity of the sender; and 

the telephone number of the sender or of the sending fax 
machine. 


All fax machines manufactured on or after December 20, 1992 and 
all facsimile modem boards manufactured on or after December 13, 
1995 must have the capability to clearly mark such identifying 
information on the first page or on each page of the 
transmission." 


5. Functional Goals for Internet Fax 


These goals for specific elements of Internet Fax follow from the 
operational goals described in section 4. 


5.1 Goals for image and other data representations 


Interoperability with Internet Mail or other transmission mechanisms 
that cause data files to appear in Internet terminal environments 
requires {1} that Internet Fax use a format for images that is in 
wide use. 


Interoperability with Internet Mail requires {2} that Internet Fax 
recipients handle those message types that are common in the email 
environment, including a minimum set of MIME mail formats. 


Interoperability with traditional fax terminals requires {1} that the 
data format be capable of representing the commonly used compression 
mechanisms defined for traditional facsimile; support for _all_ 
standard formats defined for traditional facsimile is highly 
desirable {2}. In addition, interoperability with ’private use’ 
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arbitrary bit sequences. 

5.2 Goals for transmission 


It is necessary {1} that Internet Fax to work in the context of the 
current Internet, Intranet, and the combination across firewalls. 


A single protocol with various extensions is preferable {3} to 
multiple separate protocols, if there are devices that might require, 
at different times and for different recipients, different protocols. 


5.3 Goals for addressing 


Interoperability with the terminal types in section 2 requires {1} 
the ability to address each of the kinds of recipient devices. The 
address of a recipient must give sufficient information to allow the 
sender to initiate communication. 


Interoperability with offramps to legacy fax terminals requires {1} 
that the message contain some way of addressing the final destination 
of facsimile messages, including telephone numbers, various ISDN 
addressing modes, and facsimile sub-addresses. 


Interoperability with Internet Mail requires {1} that it be possible 
to address Internet Fax to any email address. Interworking with 
Internet mail also requires {1} that the addressing is in the email 
addressing headers, including mail transport envelope [RFC1123] and 
RFC822 headers, as appropriate. The information must {1} appear 
nowhere else. 


Sending devices might not have local storage for directories of 
addresses, and addresses might be cumbersome for users to type in. 
For these reasons, Internet Fax devices may require configuration to 
locate directories of recipients and their capabilities. 


The source of a fax message must {1} be clearly identified. The 
address of the appropriate return message (whether via fax or via 
email) should {2} be clearly identified in a way that is visible to 
all manner of recipients. In the case of Internet Fax delivered by 
email, it should {2} be possible to use the normal ’reply’ functions 
for email to return a message to the sender. 


Traditionally, it is common for the first page of a fax message sent 
to a facsimile terminal to contain an (image) representation of the 
name, address, return number, etc. of the sender of the document. 
Some legal jurisdictions for facsimile require an identification of 
the sender on every page. The standard for Internet Fax should {2} 
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cover the issues of sender and recipient identification in the cases 
where fax messages are re-routed, forwarded, sent through gateways. 


5.4 Goals for Security 


Users typically use GSTN-based fax for confidential document 
transmission, assuming a similar or higher level of confidentiality 
and protection from both deliberate and inadvertent eavesdropping as 
holds for telephone conversations; the higher level of 
confidentiality arising from the requirement for non-standard 
equipment to intercept and interpret an overheard fax transmission. 


Similarly, in traditional fax there is an expectation (and, in some 
contexts, a legally recognized assurance) that the received fax is 
unaltered from the document originally transmitted. 


It is important {2} that Internet Fax give users a level of assurance 
for privacy and integrity that is as good or better than that 
available for telephone-based fax. The Internet Fax standard should 
{2} specify how secure messages can be sent, in an interoperable 
fashion. The Internet Fax protocol should {2} encourage the 
introduction of security features, e.g., by requiring that minimum 
capability devices still accept signed messages (even if ignoring the 
signature.) 


In the case where the sender is responsible for payment for offramp 
services in a remote location, it is desirable {3} to provide for 
authentication and authorization of the sender, as well as enable 
billing related information from the offramp to be transferred 
securely. 


5.5 Goals for capabilities exchange 


Traditional fax supports a wide range of devices, including high 
resolution ("Superfine"); recent enhancements include methods for 
color and a variety of compression mechanisms. Fax messaging includes 
the capability for "non-standard frames", which allow vendors to 
introduce proprietary data formats. In addition, facsimile supports 
"binary file transfer": a method of sending arbitrary binary data in 
a fax message. 


To support interoperability with these mechanisms, it should {2} be 
possible to express a wide variety of fax capabilities. 


Capability support has three elements: expression of the capabilities 
of the sender (as far as a particular message is concerned), 
expressing the capabilities of a recipient (in advance of the 
transmission of the message), and then the protocol by which 
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capabilities are exchanged. 


The Internet Fax standard should {2} specify a uniform mechanism for 
capabilities expression. If capabilities are being sent at times 
other than the time of message transmission, then capabilities should 
{2} include sufficient information to allow it to be validated, 
authenticated, etc. 


The Internet Fax standard may {3} include one or several methods for 
transmission, storage, or distribution of capabilities. 


A request for capability information, if sent to a recipient at any 
time other than the immediate time of delivery of the message, should 
{2} clearly identify the sender, the recipient whose capabilities are 
being requested, and the time of the request. Som kind of signature 
would be useful, too. 


A capability assertion (sent from recipient to sender) should {2} 
clearly identify the recipient and some indication of the date/time 
or range of validity of the information inside. To be secure, 
capability assertions should {2} be protected against interception 
and the substitution of valid data by invalid data. 


6. Security Considerations 


This document describes the goals for the Internet Fax protocol, 
including the security goals. An Internet Fax protocol must {1} 
address the security goals and provide adequate measures to provide 
users with expected security features. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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